I was thinking about this in a slightly different way: there is a use case for parsing non-string types from strings. Normally, when used with JSON, JSON parser parses strings into numbers so lollipop numeric types get numbers. However, there is a case when no pre-parser available (e.g. parsing query string parameters) so it would be nice to have a mode/types that can tolerate that.

Although this is not the same as allowing either representation (as is here). What I propose is to introduce parameter like as_string=True or stringified=True which will change behavor of non-string types (e.g. numbers or booleans) to parse & generate strings instead.

I was thinking of some kind of modifier e.g. Stringified(Integer()), but parsing of particular type is very type-specific and can not be done in a generic way outside of the type itself.

I am wondering, as this parsing is type-specific would it make sense to implement parsing in existing classes? For example by introducing an additional class, e.g. StringMixin, with a method, e.g. as_string, and then explicitly derive existing types with specific implementation, e.g. Integer(StringMixin, Type). So, this new modifier class could check that a particular type supports stringification just by checking on isinstance(inner_type, StringMixin) at Stringified(Integer()). I am worried about one thing - existing types should be changed and it is orthogonal to what you suggested.